2.4 [FD] Sections
The [FD]
sections are made up of the definition statements and a description
of what goes into the Flash Device Image. Each FD section defines one flash
"device" image. A flash device image may be one of the following: Removable
media bootable image (like a boot floppy image,) a System "Flash" image (that
would be burned into a system's flash) or an Update ("Capsule") image that will
be used to update and existing system flash.
Multiple FD sections can be defined in a FDF file.
The section header format is [FD.FdUiName]
where the FdUiName
can be any
value defined by the user. If only a single FD is constructed for a platform
then FdUiName
is optional, and the processing tools will use the DSC file
[Defines]
section's PLATFORM_NAME
value for creating the FD file.
An FD section is terminated by any other section header section or the end of the file.
This section is required for platform images, and not required for OptionROM images.
2.4.1 FD TOKEN Statements
The Token statements are used to define the physical part. These include the base address of the image, the size of the image, the erase polarity and block information. Only one of each of the valid token names can be defined in any one FD section, except as noted below.
Token = VALUE [| PcdName]
Only one token statement can appear on a single line, and each token statement must be on a single line. Multi-line token statements are not permitted.
There are five valid Token names defined by this specification.
BaseAddress
The base address of the FLASH Device.
Size
The size in bytes of the FLASH Device
ErasePolarity
Either 0 or 1, depending on the erase polarity of the Flash Device.
BlockSize
One or More - Size of a block, optionally followed by number of blocks.
Multiple BlockSize
statements are legal, and the first statement represents
block 0 (the first block) and subsequent BlockSize
statements represent
blocks 1 - N.
NumBlocks
Zero or one - The number of continuous blocks of size, BlockSize
. If
NumBlocks
is not present, the number of blocks defaults to 1.
An optional PcdName
may follow the Token statement and is separated from the
statement using a pipe "|" character. The PcdName
is assigned $(VALUE)
.
Only one PcdName
can be assigned a Token's Value.
2.4.2 FD DEFINE statements
DEFINE
statements are used to define MACRO
definitions that are scoped to
the individual FD sections. DEFINE
statements are processed in order, so a
later DEFINE
statement for a given MACRO
over-writes the previous definition.
The DEFINE
statements are typically used for creating short-cut names for
directory path names but may be used for identifying other items or values that
will be used in later statements.
DEFINE MACRO = PATH
The following are examples of the DEFINE statement.
DEFINE FV_DIR = $(OUT_DIR)/$(TARGET)_$(TOOL_CHAIN_TAG)/$(ARCH)
DEFINE MDE_MOD_TSPG = gEfiMdeModulePkgTokenSpaceGuid
DEFINE NV_STOR_VAR_SIZE = PcdFlashNvStorageVariableSize
DEFINE FV_HDR_SIZE = 0x48
DEFINE VAR_STORE_SIZE = $(MDE_MOD_TSPG).$(NV_STOR_VAR_SIZE) - $(FV_HDR_SIZE)
The $(MACRO)
can be used to create a shorthand notation that can be used
elsewhere within the FDF file. Macro values may be scoped to subsections of the
FDF file. Macros are also positional, with later values replacing values for
macros at the same level. When tools process this file, the $(MACRO)
name
will be expanded in commands or files emitted from the tools. In the following
example, $(OUTPUT_DIRECTORY)
is a variable, whose value is found in the
platform's DSC file, and this file assigns OUT_DIR
as the variable name to
use, with the same value as $(OUTPUT_DIRECTORY)
:
DEFINE OUT_DIR = $(OUTPUT_DIRECTORY)
DEFINE FV_DIR = $(OUT_DIR)/$(TARGET)_$(TOOL_CHAIN_TAG)/$(ARCH)/FV
If the DSC file declares OUTPUT_DIRECTORY = $(WORKSPACE)/Build/Nt32
,
TARGET = DEBUG
, target.txt uses MYTOOLS
for the tool chain, and the platform
is IA32
, then a statement later in the section that references $(FV_DIR)
is
interpreted by the tools as being:
$(WORKSPACE)/Build/Nt32/DEBUG_MYTOOLS/IA32/FV
2.4.3 FD SET statements
SET
statements are used to define the values of PCD statements. The current
PCD maps for regions include extra PCD entries that define properties of the
region, so the SET
statement can occur anywhere within an FD section.
SET
statements are positional within the FDF file.
SET PcdName = VALUE
Additionally, a PCD Name is made up of two parts, separated by a period "."
character. The format for a PcdName
is:
PcdTokenSpaceGuidCName.PcdCName
The following is an example of the SET
statement:
SET gFlashDevicePkgTokenSpaceGuid.PcdEfiMemoryMapped = TRUE
The VALUE
specified must match the PCD's datum type and must be the content
data.
For a PCD that has a datum type of VOID
*, the data can be a Unicode string,
as in L"text"
, a valid C data array (it must be either a C format GUID or a
hex byte array), as in {0x20, 0x01, 0x50, 0x00, 0x32, 0xFF, 0x00, 0xAA, {0xFF, 0xF0, 0x00, 0x00, 0x00}}.
For other PCD datum types, the value may be a boolean or a hex value, as in
0x0000000F,
with a value that is consistent with the PCD's datum type.
The value may also be a macro or it may be computed, using arithmetic
operations, arithmetic expressions and or logical expressions. The value
portion of the SET
statement, when using any of these computations are in-fix
expressions that are evaluated left to right, with items within parenthesis
evaluated before the outer expressions are evaluated. Use of parenthesis is
encouraged to remove ambiguity.
2.4.4 FD Region Layout
Following the FD defines section are lists of Regions
which correspond to the
locations of different images within the flash device. Currently most flash
devices have a variable number of blocks, all of identical size. When "burning"
an image into one of these devices, only whole blocks can be burned into the
device at any one time. This puts a constraint that all layout regions of the
FD image must start on a block boundary. To accommodate future flash parts that
have variable block sizes, the layout is described by the offset from the
BaseAddress
and the size of the section that is being described. Since
completely filling a block is not probable, part of the last block of a region
can be left empty. To ensure that no extraneous information is left in a
partial block, it is recommended that the block be erased prior to burning it
into the device.
Regions must be defined in ascending order and may not overlap.
A layout region start with an eight digit hex offset (leading "0x" required) followed by the pipe "|" character, followed by the size of the region, also in hex with the leading "0x" characters.
The typical layout region is terminated by the start of another region or an FV Section header.
The format for an FD Layout Region is:
Offset|Size
[TokenSpaceGuidCName.PcdOffsetCName | TokenSpaceGuidCName.PcdSizeCName] ?
[RegionType] ?
Setting the optional PCD names in this fashion is a shortcut. The two regions listed below are identical, with the first example using the shortcut, and the second using the long method:
0x000000|0x0C0000
gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress | gEfiMyTokenSpaceGuid.PcdFlashFvMainSize
FV = FvMain
0x000000|0x0C0000
SET gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress = 0x000000
SET gEfiMyTokenSpaceGuid.PcdFlashFvMainSize = 0x0C0000
FV = FvMain
The shortcut method is preferred, as the user does not need to maintain the values in two different locations.
The RegionType
, if specified, must be one of the following FV
, DATA
,
FILE
, INF
or CAPSULE
. Not specifying the RegionType
implies that the
region starting at the "Offset", of length "Size" must not be touched (unless
the region will be used for VPD data). This type of region is typically used for
event logs that are persistent between system resets, and modified via some
other mechanism (and Each FD region has a UiName
modifier, then the output
image files uses the UiName
modifier for the file name.
Note: Although sub-regions existed in EDK FDF files, EDK II FDF does not use the concept of subregions.
2.4.4.1 FV RegionType
The FV RegionType
is a pointer to either one of the unique FV names that are
defined in the [FV]
section. Both of these are files that contains a binary FV
as defined by the PI 1.0 specification. The format for the FV RegionType
is
the following:
FV = UiFvName
The following is an example of FV region type:
0x000000|0x0C0000
gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress | gEfiMyTokenSpaceGuid.PcdFlashFvMainSize
FV = FvMain
2.4.4.2 DATA RegionType
The DATA RegionType
is a region that contains is a hex byte value or an array
of hex byte values. This data that will be loaded into the flash device,
starting at the first location pointed to by the Offset value. The format of the
DATA RegionType
is:
DATA = {
The following is an example of a DATA region type.
0x0CA000 | 0x002000
gEfiMyTokenSpaceGuid.PcdFlashNvStorageBase | gEfiMyTokenSpaceGuid.PcdFlashNvStorageSize
DATA = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C
}
The !include
statement is valid for hex array portion of the DATA RegionType
.
The following is a valid usage for the !include
statement.
0x0CA000 | 0x002000
gEfiMyTokenSpaceGuid.PcdFlashNvStorageBase | gEfiMyTokenSpaceGuid.PcdFlashNvStorageSize
DATA = {
!include NvStoreInit.txt
}
2.4.4.3 FILE RegionType
The FILE RegionType
is a pointer to a binary file that will be loaded into the
flash device, starting at the first location pointed to by the Offset
value.
It should be noted that a file can be fully qualified path and filename that is
outside of the current WORKSPACE (or the directories listed in PACKAGES_PATH
system environment variable). The file must be a binary (.efi) or a raw binary
file. The format of the FILE RegionType
is:
FILE = $(FILE_DIR)/Filename.bin
Caution: If a fully qualified path and filename is specified, the platform integrator must ensure that all developers using the DSC and FDF file are aware of the requirements for this path.
The following is an example of the FILE RegionType
.
0x0CC000|0x002000
gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchAddress | gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchSize
FILE = $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/X64/Microcode.bin
# VPD Data Region
0x0026D000|0x00001000
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress
FILE = $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/FV/8C3D856A-9BE6468E-850A-24F7A8D38E08.bin
2.4.4.4 Capsule RegionType
The CAPSULE RegionType
is a pointer to a capsule section UiName
that will be
loaded into the flash device, starting at the first location pointed to by the
Offset
value. The format of the FILE RegionType
is:
CAPSULE = UiCapsuleName
The following is an example of the CAPSULE RegionType
.
0x0CC000|0x002000
gEfiTokenSpaceGuid.PcdCapsuleOffset | gEfiTokenSpaceGuid.PcdCapsuleSize
CAPSULE = MyCapsule
2.4.4.5 INF Region Type
The INF statements point to EDK component and EDK II module INF files. Parsing tools will scan the INF file to determine the type of component or module. The component or module type is used to reference the standard rules defined elsewhere in the FDF file.
The format for INF statements is:
INF [Options] PathAndInfFileName
The PathAndInfFileName is the WORKSPACE (or PACKAGES_PATH) relative path and filename.
2.4.4.6 No RegionType Specified
It is permissible to define a region with no data pre-loaded. For example,
event logging needs a data region to store events. This region is filled with
data that matches the ErasePolarity
bit during the initial installation of
the firmware or through UEFI or operating system commands and services.
An example of no region type specified is:
0x0CE000|0x002000
gEfiMyTokenSpaceGuid.PcdFlashNvStorageEventLogBase | gEfiMyTokenSpaceGuid.PcdFlashNvStorageEventLogBase